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PREFACE 


In  order  to  examine  specific  Automated  Guideway  Transit  (AGT)  developments 
and  concepts--and  to  build  a better  knowledge  base  for  future  deci sion-maki ng-- 
the  Urban  Mass  Transportation  Administration  (UMTA)  has  undertaken  a 
program  of  studies  and  technology  investigations  called  the  UMTA  Automated 
Guideway  Transit  Technology  (AGTT)  program.  The  objectives  of  one  segment 
of  the  AGTT  program,  the  Systems  Operation  Studies  (SOS),  were  to  develop 
models  for  the  analysis  of  system  operations,  to  evaluate  performance  and 
cost,  and  to  establish  guidelines  for  the  design  and  operation  of  AGT  systems. 

A team  headed  by  GM  Transportation  Systems  Division  (GMTSD)  was  awarded 
a contract  by  the  Transportation  Systems  Center  to  pursue  these  objectives. 

The  Technical  Monitor  for  the  project  at  TSC  was  Arthur  Priver,  who  was 
assisted  by  Li  Shin  Yuan  and  Thomas  Dooley. 

The  Detailed  Station  Model  (DSM)  is  a discrete  event  model  representing 
the  i nter-rel ated  queueing  processes  associated  with  vehicle  and  passenger 
activities  in  an  AGT  station.  The  DSM  can  be  used  to  analyze  alternative 
station  configurations  and  management  policies.  This  Functional  Specification 
identifies  the  functions  performed,  the  hardware  required,  and  the  modeling 
technique  employed  by  the  DSM. 

This  document  was  prepared  under  the  direction  of  the  SOS  Program  Manager 
at  GMTSD,  James  F.  Thompson.  The  first  draft  of  this  report  was  prepared 
by  the  IBM  Federal  Systems  Division  (FSD)  under  the  direction  of  Roger  Blanchard, 
and  its  final  preparation  was  the  responsibility  of  James  G.  Bender  of  GMTSD. 
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1.0  INTRODUCTION 


1 . 1 Objectives 

The  Detailed  Station  Model  (DSM)  will  provide  operational  and  performance  measures  of 
alternative  station  configurations  and  management  policies  with  respect  to  vehicle  and 
passenger  handling  capabilities.  A discrete  event  modeling  approach  will  be  used  to 
represent  the  interrelated  queueing  processes  associated  with  vehicle  and 
passenger  activities  in  a transit  station. 

The  DSM  will  provide  an  analytic  tool  to  support  trade  studies  and  evaluations  of  alterna- 
tive station  designs.  Flexibility  and  modularity  will  be  emphasized  in  the  model  to  allow 
detailed  analysis  of  station  configurations,  operations,  and  station  management  policies. 

The  model  architecture  will  facilitate  interchange  of  alternative  operational  strategy 
algorithms  and  station  traffic  flow  patterns  to  assist  in  the  initial  station  design  selection 
by  planners. 

The  station  operational  characteristics  produced  by  the  DSM  will  be  analyzed  to  define 
accurate  station  representations  for  use  in  the  Discrete  Event  Simulation  Model. 

The  capabilities  of  the  DSM  will  permit  the  evaluation  of  station  performance  under  vary- 
ing configurations,  vehicle  load,  passenger  load,  and  operation  methods.  Through  the 
selection  of  appropriate  run  options  and  input  variables,  the  model  response  will  range  from 
simple  to  complex,  e.g.,  the  physical  station  configuration  being  simulated  could  be  a 
single  dock  on-line  station  or  a station  with  several  docks,  vehicle  storage,  and  modal 
interchange,  representing  an  off-line  Dual  Mode  station.  Operating  decisions  tend  to 
increase  in  proportion  to  the  level  of  detail  being  represented.  The  DSM  accommodates 
a range  of  decision  points  for  vehicle  motion,  passenger  flow,  trip  management,  vehicle 
disposition,  merging,  and  berthing. 

1.2  Scope 

This  section  lists  the  design  constraints  and  limitations  of  the  baseline  Detailed  Station 
Model.  These  factors  are  mainly  in  the  area  of  representing  a network  operational  environ- 
ment and  of  specifying  maximum  values  for  quantities  and  capacities  of  station  elements. 

Those  DSM  features  which  pertain  only  to  the  baseline  capability  will  be  implemented  in 
a manner  which  will  permit  substitution  of  feasible  alternative  procedures  or  algorithms 
derived  as  a result  of  AGT-SOS  analysis  tasks.  The  feasibility  of  substituting  for  these 
baseline  features  will  be  established  by  considering  their  impact  on  the  basic  model  archi- 
tecture and  the  data  interface  requirements. 

In  multiparty  service,  a group  of  passengers  traveling  together  will  not  be  broken  up  to 
fill  empty  seats  on  several  vehicles.  The  group  will  wait  for  a vehicle  that  has  sufficient 
room.  In  single  party  service,  if  the  group  size  is  larger  than  the  capacity  of  an  empty 
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vehicle,  the  group  will  be  broken  up  and  assigned  to  multiple  vehicles. 

Waiting  trips  are  not  passed  over  when  assigning  trips  to  vehicles  to  maximize  the  use  of 
vehicles.  Assignment  is  on  a first-in-first-out  basis,  except  for  multiparty  service  in 
which  the  destination  of  boarding  trips  must  be  compatible  with  the  trips  already  on  board. 
Compatibility  for  demand-responsive  multiparty  service  is  established  through  the  use  of  a 
probability  of  compatibility.  Compatibility  for  scheduled  service  is  established  through  the 
use  of  a table  which  gives  the  destinations  associated  with  each  route  (here  the  destination 
of  the  trip  must  be  on  the  route  of  the  vehicle  to  be  boarded)  or  through  the  use  of  a 
probability  of  compatibility. 

Transfers  will  be  required  to  join  the  end  of  the  trip  queue  (i.e.,  no  priority).  Required 
transfers  will  be  identified  by  the  use  of  a user  specified  probability  of  transfer  of  those 
trips  on  the  vehicle  that  are  not  to  destinate  at  the  station  being  simulated. 

No  provision  will  be  made  for  multiple  sized  vehicles  in  a single  run.  No  distinction 
between  seating  and  standing  capacity/occupancy  will  be  made. 

Approximate  vehicle  launch  time  will  be  obtained  from  a specified  distribution  of  delays, 
when  the  vehicle  is  at  the  head  of  an  output  queue  lane.  No  network  merge  reservation 
or  metering  schemes  will  be  included  in  the  model. 

In  the  case  of  scheduled  service,  any  delay  necessary  to  keep  the  vehicle  on  a schedule 
will  be  added  to  the  delay  discussed  above. 

For  asynchronous,  quasi-synchronous,  and  synchronous  vehicle  control,  a delay  will  be 
calculated  to  represent  the  delay  a vehicle  would  have  to  undergo  to  ensure  that  it  did 
not  conflict  with  a vehicle  from  the  bypass  link  at  the  station  exit  merge. 

The  user  will  have  the  option  of  including  (additively)  or  excluding  the  above  three 
components  of  launch  delay. 

No  network  level  handling  of  empty  vehicles  will  be  included.  If  an  empty  is  requested, 
it  will  arrive  at  a randomly  selected  delay  time  later.  If  a vehicle  becomes  empty  at  the 
dock  and  is  not  needed,  it  will  either  be  sent  to  storage  or  dispatched  from  the  station 
(simulating  an  empty  vehicle  request  from  another  station).  The  decision  will  be  either 
deterministic  from  a function  derived  by  the  user  or  by  random  selection  from  a user 
specified  distribution.  If  storage  is  full,  the  vehicle  will  be  dispatched  from  the  station. 

Vehicle  movement  within  a station  element  will  be  modeled  by  a travel  time  based  on  a 
vehicle  velocity  profile.  Element  capacity  and  vehicle  headway  leaving  the  element  will 
be  considered. 
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Station  configuration  limitations  will  include  the  following: 


• Maximum  number  of  parallel  queue  areas  for  vehicles  10 

• Maximum  number  of  docking  lanes  10 

• Maximum  number  of  berths  per  lane  6 

• Maximum  number  of  vehicles  200 

• Maximum  number  of  concurrent  trips  1,000 

• Number  of  entry  ramps  from  guideway  1 

• Number  of  exit  ramps  to  guideway  1 

• Number  of  model  entry  ramps  into  input  queue  area  1 

• Number  of  modal  entry  ramps  into  output  queue  area  1 

• Number  of  modal  exit  ramps  from  input  ramp  1 

• Number  of  modal  exit  ramps  from  boarding  area  1 


If  an  offline  station  becomes  congested,  arriving  vehicles  destined  for  the  station  will  not 
queue  on  the  guideway.  They  will  be  recorded  as  station  rejections  and  enter  the  bypass 
link. 

It  will  not  be  possible  to  change  any  operational  policies  during  a simulation  exercise. 

This  effect  will  be  simulated  by  the  use  of  checkpoint  files  and  simulation  restart 
capability. 

Passengers  can  be  affected  by  failures,  but  will  not  cause  failures. 

With  respect  to  modeling  entrained  vehicles  in  a scheduled  (i.e.,  fixed  route)  environment, 
there  will  be  a capability  to  generate  trains  of  vehicles  during  the  demand  generation 
process.  The  number  of  vehicles  per  train  will  be  specified  for  each  route  by  the  user 
(e.g.,  all  trains  on  route  1 have  three  vehicles;  all  trains  on  route  2 have  five  vehicles, 
etc.).  In  the  event  processor,  these  trains  will  arrive  on  the  link  prior  to  the  station, 
may  enter  the  station,  undergo  station  processing,  and  go  out  as  trains.  The  "switchover" 
operation  of,  for  example,  changing  all  trains  on  a route  from  three  vehicles  to  two 
vehicles,  will  not  be  modeled  for  the  scheduled  environment. 

The  modeling  of  entrainment  in  the  demand  responsive  environment  will  be  accomplished 
in  the  output  area  by  entraining  an  entering  vehicle  to  the  vehicle  serially  ahead  of  it 
if  they  have  compatible  next  destinations.  The  launch  time  of  a vehicle  will  be  calculated 
when  a vehicle  is  at  an  output  queue  lane  and  available  for  launch.  At  launch  time, 
if  the  head  vehicle  in  a lane  is  entrained,  then  it  and  its  followers  will  be  launched  at 
once.  Vehicles  are  considered  to  be  detrained  automatically  at  the  boarding  berth  and 
will  be  reentrained  in  an  output  queue  lane  if  the  criteria  discussed  above  are  met. 
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2.0  REQUIREMENTS 


2.1  Functions 


The  DSM  functions  described  below  provide  the  definition  of  a baseline  simulation  capability 

Those  DSM  features  which  pertain  only  to  the  baseline  capability  will  be  implemented  in  a 
manner  which  will  permit  substitution  of  feasible  alternative  procedures  or  algorithms 
derived  as  a result  of  AGT-SOS  analysis  tasks.  The  feasibility  of  substituting  for  these 
baseline  features  will  be  established  by  considering  their  impact  on  the  basic  model 
architecture  and  the  data  interface  requirements. 

2.1.1  Demand  Generation 


There  will  be  four  sources  of  demand  input  to  the  Detailed  Station  Model: 

• Vehicles  (with  trips  onboard)  arriving  from  the  guideway 

• Vehicles  (with  trips  onboard)  arriving  from  modal  entry  into  input  queueing  area 

• Vehicles  (with  trips  onboard)  arriving  from  modal  entry  into  output  queueing  area 

• Trips  arriving  at  the  ticketing  facility 

Four  sinks  of  demand  will  be  provided  in  the  Detailed  Station  Model: 

• Vehicles  (with  trips  onboard)  departing  on  guideway 

• Vehicles  (with  trips  onboard)  departing  on  modal  exit  from  input  ramp 

• Vehicles  (with  trips  onboard)  departing  on  modal  exit  from  boarding  area 

• Trips  departing  from  the  deboard  area 

The  DSM  will  provide  the  capability  to  generate  data  for  the  four  sources  from  the  following 
generators  (in  addition,  the  DSM  will  accept  as  input  any  properly  formatted  and  time 
ordered  demand  coded  to  reflect  a specific  demand  situation  as  desired  by  the  simulation  user) 

• Vehicles  from  guideway: 

— DESM  copied  to  a file  as  vehicles  pass  a specified  station 
— Vehicle  Demand  Generator  (VDG)  - part  of  input  processor 

• Vehicles  from  modal  entry  into  input  queueing  area: 

- VDG 

— Feeder  model  (converted  into  a sequence  of  vehicles  in  the  same  format 
as  from  VDG) 

• Vehicles  from  modal  exit  into  output  queueing  area: 

- VDG 

— Feeder  model  (converted  into  a sequence  of  vehicles  in  the  same  format 
as  from  VDG) 
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• Trips 

— Trip  Demand  Generator  (TDG) 

— Asynchronous  trip  arrivals: 

+ Input  as  a command  (e.g.,  a failure  command) 

+ Used  to  force  a set  of  trips  arriving  simultaneously 
+ Will  be  interleaved  with  TDG  source 

The  four  sources  of  demand  will  be  read  into  the  Event  Processor  from  four  separate  files 
(i.e.,  not  interleaved  in  time  on  1 file).  This  will  allow  the  files,  which  are  generated 
before  they  are  used  in  the  Event  Processor,  to  be  used  in  any  combination.  These  sources 
will  be  time  interleaved  at  Event  Processor  execution  time. 

The  remainder  of  this  section  will  discuss  the  TDG  and  VDG  functions  of  the  Input  Processor. 
Trip  Demand  Generation  (TDG) 

For  trips  arriving  at  the  ticketing  facility,  each  trip  will  have  the  following  attributes: 

• Arrival  time  at  the  station  being  simulated  - Arrivals  will  occur  with  a mean 
arrival  rate  as  specified  by  the  user,  with  individual  trips  specified  by  Poisson 
distributed  pseudo-random  numbers  or  user  specified  distribution  table  of 
interarrival  time 

• Origin  station  - Set  equal  to  the  station  being  simulated 

• Destination  station  - Selected  by  using  pseudo-random  numbers  and  a table 
giving  the  probability  of  each  destination  station 

• Number  of  passengers  - Selected  by  using  pseudo-random  numbers  and  a table 
giving  the  probability  of  1 passenger,  2 passengers,  etc. 

The  user  will  be  able  to  control  the  mean  arrival  rate  and  distribution  tables  used  in  this 
generation  process.  These  tables  will  be  generated  by  a portion  of  the  Input  Processor 
and  will  be  available  in  the  data  base  for  use  in  several  experiments. 


Vehicle  Demand  Generation  (VDG) 

Vehicles  that  are  to  enter  the  simulation  will  be  represented  by  a set  of  records,  the  first 
of  which  will  be  a vehicle  header  record  and  a set  of  trip  follower  records  (one  per  trip). 

In  VDG,  provision  will  be  made  to  generate  vehicles  corresponding  to  a scheduled  or  demand 
responsive  environment. 

In  the  case  of  a scheduled  environment,  where  vehicles  stop  at  stations  on  a pre-assigned 
route,  the  header  record  will  be  generated  as  follows: 
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• Arrival  time  of  the  vehicle  at  the  station  being  simulated  (on  the  guideway  link 
immediately  upstream  of  the  station)  - Arrivals  will  occur  at  a mean  arrival  rate 
as  specified  by  the  user  for  each  route,  with  individual  arrival  times  selected 
using  Poisson  distributed  pseudo-random  numbers  or  user  specified  distribution 
table  of  interarrival  times.  In  the  case  of  asynchronous  and  quasi-synchronous 
control,  the  generation  process  will  ensure  serialization  by  making  the 
interarrival  time  between  any  two  consecutive  vehicles  greater  than  or  equal  to 
a user  specified  headway  parameter.  In  the  case  of  synchronous  control, 

the  generation  process  will  ensure  the  vehicles  are  in  slots  by  considering  each 
particular  interarrival  time  selected  to  be  a multiple  of  time  slot  lengths. 

• The  next  stop  of  the  vehicle  - Set  equal  to  the  station  being  simulated  if  the 
station  is  on  the  route  of  the  vehicle  and  set  equal  to  some  other  value  otherwise 
(The  user  may  specify  either  a list  of  station  numbers  for  each  route  or  a binary 
indicator  for  eadh  route  to  show  if  the  station  is  on  route  of  the  vehicle  or  not) 

• The  route  of  the  vehicle  - Included  for  subsequent  use  in  determining  the 
compatibility  of  trips 

• Sink  of  the  vehicle  - Determined  with  a probability  for  each  of  the  three 
vehicle  sinks  discussed  above 

Trip  follower  records  will  be  generated  using  a stochastic  process  as  follows: 

• The  arrival  time  of  the  trip  - Set  equal  to  the  arrival  time  of  the  vehicle 

• The  destination  of  the  trip  - Selected  using  pseudo-random  numbers  and  a table 
giving  the  probability  that  the  trip  will  destinate  at  the  station  being  simulated 

• Number  of  passengers  in  the  trip  - Selected  using  a pseudo-random  number  and  a 
user  specified  distribution  giving  the  probability  of  1 patron,  2 patrons,  etc. 

The  number  of  trips  associated  with  a vehicle  will  be  selected  using  pseudo-random  numbers 
and  a user  specified  distribution  that  gives  the  probability  of  1 trip,  2 trips,  etc. 

When  generating  trains,  the  user  will  specify  the  number  of  vehicles  per  train  for  each 
route.  Each  vehicle  in  such  a train  will  have  the  same  arrival  time. 

In  the  case  of  demand  responsive  environment,  where  the  vehicles  follow  paths  on  the 
basis  of  trips  assigned  to  them,  the  vehicle  header  record  will  be  generated  as  follows: 

• Arrival  time  of  the  vehicle  at  the  station  being  simulated  (on  the  guideway  link 
immediately  upstream  of  the  station  or  at  the  modal  entry)  - Arrivals  will  occur 
at  a single  mean  arrival  rate  as  specified  by  the  user,  with  individual  arrival 
times  determined  by  using  an  exponential  interarrival  time  distribution  or  a 
user-specified  distribution  table  of  interarrival  times 


6 


In  the  case  of  asynchronous  and  quasi -synchronous  control,  the  generation  process  will 
provide  for  serialization  by  ensuring  that  the  interarrival  time  between  any  two  consecutive 
vehicles  is  greater  than  or  equal  to  a user  specified  headway  parameter.  In  the  case  of 
synchronous  control,  the  generation  process  will  ensure  the  vehicles  are  in  slots  by 
considering  each  particular  interarrival  time  selected  to  be  a multiple  of  the  slot 
lengths . 

• Next  stop  of  the  vehicle  - Will  be  set  equal  to  the  station  being  simulated 
with  a probability  specified  by  the  user 

o Route  of  the  vehicle  - Will  not  be  set  in  this  case 

9 Sink  of  the  vehicle  - Determined  with  a probability  for  each  of  the  three 
vehicle  sinks  discussed  above 

Trip  follower  records  will  be  generated  using  pseudo-random  numbers  as  follows: 

9 Arrival  time  of  the  trip  - Set  equal  to  the  arrival  time  of  the  vehicle 

9 The  destination  of  the  trip  - Selected  using  pseudo-random  numbers  and 
the  probability  a trip  will  destinate  at  the  station  being  simulated 

9 Number  of  passengers  in  the  trip  - Selected  using  a pseudo-random  number 
and  a table  that  gives  the  probability  of  1 patron,  2 patrons,  etc. 

The  number  of  trips  associated  with  the  vehicle  will  be  selected  using  pseudo-random 
numbers  and  a user  specified  distribution  giving  the  probability  of  1 trip,  2 trips,  etc. 

The  number  of  trips  will  be  limited  by  vehicle  capacity.  When  generating  trains,  the 
user  will  specify  a distribution  for  choosing  1 -vehicle  trains,  2-vehicle  trains,  etc. 

Each  vehicle  in  such  a train  will  have  the  same  arrival  time. 

Vehicle  demand  files  will  be  generated  by  a portion  of  the  Input  Processor  and  stored  in 
the  data  base.  They  will  be  available  for  use  in  several  experiments  in  which  the  vehicle 
size  is  the  same  as  that  used  during  generation. 

2.1.2  Trip  Management 

Trip  Management  relates  to  the  management  of  trips  while  they  are  not  on  vehicles.  When 
a trip  arrives,  whose  number  of  passengers  exceeds  the  size  of  a single  vehicle,  it  will  be 
subdivided  at  entry  to  the  station  and  treated  as  N sub-groups  trips  of  fixed  size  as  input 
by  the  user  plus  one  other  trip  to  accommodate  the  residual  patrons.  Thereafter,  it  will 
be  treated  as  N+l  independent  trips. 

An  overview  of  the  time  line  of  a trip  (i.e.,  the  successive  delays  it  may  encounter  while 
not  on  a vehicle)  and  an  overview  of  the  trip  handling  facilities  are  given  in  Figure  1 . 
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When  a trip  arrives  at  a station,  it  will  be  processed  by  a ticketing  facility.  If  all  the 
ticketing  servers  are  busy  or  if  the  next  area  to  be  entered,  the  Turnstile  Area,  is  at 
capacity,  then  the  trip  will  queue  in  the  Ticketing  Area.  Following  ticket  processing, 
the  trip  will  enter  the  Turnstile  Area  and  queue  there  if  either  all  the  turnstile  servers 
are  busy  of  if  the  Boarding  Area  is  a capacity.  After  turnstile  processing,  the  trip  will 
enter  the  Boarding  Area  to  wait  for  an  appropriate  vehicle.  Boarding  trips  will  experience 
a delay  time  sampled  from  a distribution  based  on  the  number  of  boarding  passengers  and 
door  actuation  time.  Deboarding  passengers  will  experience  a delay  time  sampled  from 
a distribution  based  on  the  number  of  boarding  passengers  and  door  actuation  time.  In 
the  case  of  a common  boa rding/de boarding  area  a delay  time  sampled  from  a distribution 
based  on  the  number  of  boarding  and  deboarding  passengers  will  model  the  interaction 
effects  of  the  common  areas. 

Required  transfers  will  be  identified  by  the  use  of  a user  specified  probability  of  transfer 
of  those  trips  on  the  vehicle  that  are  not  to  destinate  at  the  station  being  simulated.  In 
the  DSM  baseline,  transfers  will  be  assigned  to  the  end  of  the  boarding  queue  (i.e.,  no 
priority). 

The  capacities  of  the  three  areas  are  user  specified  and  will  be  used  to  evaluate  the 
adequacy  of  various  station  configurations.  A trip  will  not  be  allowed  to  enter  the  next 
area  unless  that  area  is  below  capacity;  instead,  it  will  queue  in  the  area  it  is  currently 
in  and  block  the  processing  function  of  that  area.  When  an  area  goes  below  capacity, 
trips  that  have  been  waiting  to  enter  will  then  flow  info  that  area. 


2.1.3  Vehicle  Selection 

Vehicle  selection  relates  to  the  process  of  associating  a trip  with  a vehicle.  In  the  DSM 
baseline,  two  forms  of  service  will  be  provided  regarding  the  use  of  vehicles:  demand 
responsive  and  scheduled.  These  service  modes  are  defined  below,  together  with  their 
vehicle  selection  rules. 


2. 1.3.1  Demand  Responsive  Service 

In  this  service  mode,  vehicles  are  not  assigned  to  routes  but,  rather,  follow  the  routes 
necessary  to  service  the  trips  assigned  to  them.  Since  the  DSM  does  not  contain  a 
dynamic  representation  of  the  remainder  of  the  network,  vehicles  will  not  continually 
exist  in  the  simulation.  When  a vehicle  leaves  the  station  model,  its  transaction  will  be 
reclaimed. 

Trips  are  assigned  to  vehicles  when  a vehicle  arrives  at  a station  berth  and  is  available 
for  boarding.  However,  when  a trip  arrives  at  the  boarding  queue,  a search  will  be  made 
for  a vehicle  to  ensure  that,  in  fact,  a given  trip  will  be  serviced.  This  search  procedure 
differs  from  single  party  and  multiparty  service. 
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Foi  single  party  service,  the  user  will  select  a priority  ordering  on  the  following  sources: 

• At  the  berth  currently  unloading  or  upstream  of  it  in  the  station 

• An  empty  from  local  storage 

• An  empty  from  elsewhere  in  the  network 


These  sources  will  be  searched  in  the  order  specified  by  the  user.  In  the  event  it  is  necessary 
to  call  for  an  empty  vehicle  from  elsewhere  in  the  network,  a user  specified  delay  time 
distribution  table  will  be  used  to  determine  the  arrival  time  of  an  empty  vehicle  at  the 
station  being  modeled.  At  this  time  a vehicle  transaction  will  be  initialized  to  represent 
an  empty  vehicle  arriving  on  the  guideway  upstream  of  the  station. 

In  the  multiparty  case,  the  vehicle  selected  has  the  same  possibilities  as  the  single  party 
case,  except  that  in  considering  vehicles  due  to  arrive  shortly  or  currently  unloading,  a 
simulated  check  of  the  compatibility  of  destinations  will  be  made  using  a probability  of  a 
compatible  vehicle  entered  by  the  user. 

2. 1.3. 2 Scheduled  Service 


In  scheduled  service,  vehicles  are  preassigned  to  various  circuitous  routes  with  defined 
station  stops.  One  data  item  in  the  vehicle  header  record  from  the  vehicle  demand  file 
will  be  the  route  of  the  vehicle.  Trips  are  assigned  to  vehicles  when  the  vehicle  arrives 
at  the  station  berth  and  is  available  for  boarding.  For  a trip  to  be  considered  for 
assignment  to  a vehicle,  the  trip's  destination  must  match  one  of  the  assigned  stops  of  the 
route  of  the  vehicle,  if  the  user  had  specified  a station  list  for  each  route.  Otherwise, 
compatibility  will  be  determined  using  a user  specified  probability.  More  than  one  trip 
may  board  the  vehicle,  subject  to  the  vehicle  capacity  constraint.  Each  succeeding  trip 
that  will  be  serviced  will  be  the  first  assignable  trip  that  can  be  accommodated. 

2.1  .4  Station  Management 

Station  Management  relates  to  the  management  of  vehicles  (especially  occupied  vehicles) 
within  the  station.  Empty  Vehicle  Management,  which  determines  what  is  to  be  done 
with  an  empty  vehicle,  will  be  treated  in  Section  2.1.5. 

The  management  of  vehicles  within  the  station  is  largely  controlled  by  the  configuration 
of  the  station.  In  order  to  achieve  flexibility  in  being  able  to  model  various  station 
configurations,  the  DSM  will  contain  a general  station  configuration  in  which  components 
can  be  parametrically  excluded  and/or  varied  in  size.  Alternative  physical  layouts 
are  modeled  by  changing  the  parameters  input  to  the  general  station  conficutration . 

For  example: 

• Parametrically  excluding  the  bypass  link  would  convert  it  to  an  on-line  station 
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9 Parametrically  excluding  the  travel  delay  between  the  deboarding  process  and 
the  boarding  process  would  convert  it  from  a station  with  separate  deboarding 
and  boarding  areas  to  one  with  common  areas 

• Parametrically  varying  the  number  of  parallel  lanes  and  number  of  serial 
berths  per  lane  could  be  used  to  create  a station  with  one  lane  of  N serial 
berths,  M lanes  of  one  serial  berth  each,  or  a combination 


o Parametrically  excluding  the  Input  Queueing  Area,  Output  Queueing  Area, 
Storage  Area,  or  Modal  Entry/Exit  Areas  could  also  be  used  to  vary  the 
configuration  of  the  station 

An  overview  diagram  of  this  general  station  configuration  is  given  in  Figure  2.  A more 
in-depth  view  depicting  the  component  delays  that  a vehicle  may  encounter  in  the 
baseline  station  model  is  provided  in  the  preliminary  Vehicle  Time  Line  diagram  of 
Figure  3.  Vehicle  movement  through  the  station  will  conform  to  assigned  travel  time, 
queue  delays  imposed  by  decision  logic,  dwell  delays,  and  launch  delays.  The  various 
areas  of  the  station  will  have  user  specified  capacities.  When  an  area  is  at  capacity, 
vehicles  in  upstream  areas  will  experience  queueing  delays.  When  the  occupancy  of  an 
area  drops  below  capacity,  vehicles  waiting  in  upstream  areas  will  be  allowed  to  enter. 
When  two  vehicles  are  serially  positioned  with  respect  to  each  other,  the  upstream  vehicle 
may  experience  a queueing  delay  waiting  for  the  downstream  vehicle  to  move;  when  the 
downstream  vehicle  moves,  vehicles  upstream  of  if  that  have  been  waiting  may  also  move. 

One  of  the  more  significant  delays  in  the  station  is  the  launch  delay.  The  factors 
influencing  the  launch  delay  are: 

© Presence  of  another  vehicle  serially  in  front  of  the  vehicle  to  be  launched 

© Schedule  for  the  vehicle  - In  the  case  of  Scheduled  Service,  the  departure 
time  of  each  vehicle  on  a given  route  will  either  be  preassigned  (fixed 
schedule)  as  a function  of  the  vehicle's  cycle  or  will  be  determined  dynamically 
for  each  departing  vehicle  (i.e.,  select  a departure  time  that  is  midway 
between  the  previous  departure  time  on  that  route  and  the  estimated  arrival  time 
of  the  next  vehicle  on  that  route).  In  both  of  these  cases,  if  the  desired 
launch  time  has  passed,  then  the  vehicle  should  be  launched  as  soon  as  possible. 
In  the  case  of  demand  responsive  service,  the  vehicle  should  be  launched 
as  soon  as  possible. 

® Coordinating  merges  in  the  rest  of  the  network  - Since  this  is  a stand-alone 
station  model,  delay  due  to  this  type  of  factor  will  be  modeled  using  a user 
specified  delay  time  distribution  table. 

9 Coordinating  merge  with  the  bypass  link 
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FIGURE  2 OVERVIEW  OF  STATION  CONFIGURATION 
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FIGURE  3 VEHICLE  TIME  LINE 


Foi  asynchi  onous,  quasi -synchronous,  and  synchronous  vehicle  control,  a delay  will  be 
calculated  to  represent  the  delaya  vehicle  would  have  to  undergo  to  ensure  it  did  not 
conflict  with  a vehicle  from  the  bypass  link  at  the  station  exit  merge.  This  will  be  done 
by  assuming  a constant  velocity  and  bypass  link  velocity  (as  specified  by  the  user),  together 
with  the  time  vehicles  arrived  at  the  station  entry  (start  of  bypass  link). 

The  pi eceding  factors  influencing  launch  delay  will  be  coordinated  as  follows.  In  all 
cases  the  first  factor  will  be  observed,  in  that  the  launch  delay  will  not  be  calculated 
until  the  vehicle  is  at  the  top  of  a serial  queue  and  able  to  be  launched.  The  other  three 
factors  will  be  additively  included  or  excluded  from  the  launch  delay  based  on  a user  option. 

With  respect  to  modeling  entrained  vehicles  in  a schedule  (i.e.,  fixed  route)  environment, 
there  will  be  a capability  to  generate  trains  of  vehicles  in  the  demand  generation  process 
of  the  Input  Processor.  The  number  of  vehicles  per  train  will  be  specified  for  each  route 
by  the  user  (e.g.,  all  trains  on  Route  1 have  three  vehicles,  all  trains  on  Route  2 have 
five  vehicles,  etc.).  In  the  Event  Processor,  these  trains  will  arrive  on  the  link  prior  to 
the  station,  may  enter  the  station,  undergo  station  processing,  and  go  out  as  trains.  The 
"switchover"  operation  of,  for  example,  changing  all  trains  on  a route  from  three  vehicles 
to  two  vehicles  will  not  be  modeled  for  the  scheduled  environment. 

For  the  demand  responsive  environment,  when  a vehicle  enters  the  output  queue  area,  the 
entering  vehicle  will  be  entrained  to  the  vehicle  serially  ahead  of  if  in  the  output  queue 
lane  if  they  have  the  same  next  stop.  The  launch  time  of  a vehicle  will  be  calculated 
only  when  the  vehicle  is  at  an  output  queue  lane  and,  hence,  available  for  launch.  At 
launch  time,  if  the  head  vehicle  in  a lane  is  entrained,  then  if  and  its  followers  will  get 
launched  at  once.  Vehicles  are  considered  to  be  detrained  automatically  at  the  boqrding 
berth  and  will  be  refrained  in  an  output  queue  lane  later  if  the  criteria  discussed  above 
are  met.  Further,  the  user  will  be  allowed  to  specify  the  number  of  output  queue  lanes 
either  equal  to  the  number  of  boarding  area  lanes  or  equal  to  one. 

2.1.5  Empty  Vehicle  Management 

Under  demand  responsive  service,  vehicles  that  become  empty  will  become  the  responsibility 
of  Empty  Vehicle  Management.  Note  that  for  scheduled  service,  all  vehicles  remain 
committed  to  routes,  so  Empty  Vehicle  Management  does  not  become  involved  in  that  case. 

In  the  Detailed  Station  Model,  there  will  be  two  places  to  put  empty  vehicles:  in  storage 
of  the  station  being  modeled  or  elsewhere  in  the  network  (corresponding  to  sending  it  to  a 
nearby  station  to  service  a waiting  trip,  to  a regional  storage  center,  or  to  circulate  on  the 
guideway).  The  user  will  have  the  option  of  specifying  either.  If  the  user  specifies  that 
an  empty  vehicle  is  to  be  sent  to  storage,  a user  specified  probability  will  be  used  to 
simulate  those  instances  where  a vehicle  would  normally  be  sent  to  local  storage  but  is 
now  to  be  sent  out  to  service  a waiting  trip  at  a nearby  station.  If  the  vehicle  is  to  be 
sent  to  local  storage,  then  a test  will  be  made  to  see  if  local  storage  is  at  capacity.  If 
the  vehicle  is  to  service  a waiting  trip  at  a downstream  station,  or  if  local  storage  is  at 
capacity,  then  the  vehicle  will  be  directed  out  of  the  station  by  calculating  a launch 
time,  etc.,  just  as  with  occupied  vehicles. 
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2.1.6  Failure  and  Recovery 


Station  failures  will  be  represented  as  explicit  commands  to  impede  the  transit  operation. 
The  failure  command  will  contain: 

• Failure  initiation  time 

• Location  (link,  docking  area,  etc.) 

• Failure  recovery  time 

• First  vehicle  to  enter/next  vehicle  to  exit  (links,  lanes,  docking  area) 

• Degrade/complete  failure 

In  addition,  the  capability  to  fail  passenger  management  equipment  will  be  provided. 

As  a result  of  a failure  command  initially  affecting  a particular  vehicle,  that  vehicle 
will  be  considered  halted.  At  recovery  time,  the  recovery  procedure  will  be  implemented, 
restoring  appropriate  equipment  to  operational  status  and  dequeueing  will  be  initiated 
to  start  appropriate  vehicles  moving.  A failure  affecting  passengers  (not  vehicles)  will  be 
similarly  approached.  A checkpoint  file  will  be  created  for  the  failure. 

2.2  Input  Parameters 

This  section  lists  the  model  input  and  run  time  variables  in  terms  of  system,  configuration, 
trip,  and  algorithm  related  inputs.  All  of  the  input  parameters  are  included  in  the  input 
and  description  file  of  the  simulation  data  base.  The  model  input  processor  operates 
on  this  data,  performing  reasonableness  checks  and  computing  event  oriented  data  for  the 
model  processor.  The  processed  data  is  placed  in  a structured  data  file  of  the  data  base 
to  be  used  at  run  time  by  the  model  processor. 

2.2.1  System  Parameters 

• Event  timing  variables 

— Clock  scale  factor 

— Spacing  between  successive  clock  table  entries 
— Spacing  between  multiple  thread  transactions 

• Statistics  sampling  interval 

• Run  stop  time 

2.2.2  Configuration  Parameters 

• Link  lengths 

• Link  connectivity 

• Number  of  entrance  queues 

• Capacity  of  entrance  queues 

• Number  of  vehicle  berthing  lanes 

• Number  of  vehicle  berths  per  lane 
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® Number  of  exit  queues 

• Capacity  of  exit  queues 

® Capacity  of  empty  vehicle  storage 
9 Vehicle  speed  on  links 
9 Vehicle  speed  in  station 
® Vehicle  acceleration/deceleration/jerk 
® Passenger  boarding/deboarding  time  delay  distributions 

• Passenger  transfer  time 

• Vehicle  retrieval  from  storage  time 

• Launch  delay  distributions 

• Modal  interchange  time 
® Vehicle  capacity 

• Vehicle  length 

9 Vehicle  headway  on  guideway 
9 Vehicle  headway  in  station 
9 Time  distribution  for  passenger  ticketing 
9 Time  distribution  for  boarding  area  access 
® Capacity  of  ticketing  queue 
® Capacity  of  boarding  area  access  queue 

2.2.3  Trip  Parameters 


9 Vehicle  arrivals 
— Time 

— Number  of  passengers  to  deboard 
— Number  of  passengers  transferring  and  destinations 
— Number  of  passengers  continuing  and  destinations 

9 Pedestrian  arrivals 
— Time 
— Group  size 
— Destination 

9 Modal  interchange  arrivals 
— Time 

— Number  of  passengers  transferring  and  destinations 
— Number  of  passengers  continuing  and  destinations 


2.2.4  Algorithm  Parameters 


® Multiparty  policy  selection 
9 Berthing  policy  selection 
9 Launch  policy  selection 
9 Empty  vehicle  policy  selection 
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2.3  Outputs 


This  section  lists  the  station  performance  and  operational  characteristics  data  to  be  computed 
and  output  by  the  DSM.  The  data  will  be  written  to  the  data  base  raw  statistics  file 
periodically  during  each  simulation  exercise  as  defined  by  the  sampling  interval  input 
parameter.  The  model  output  processor  will  subsequently  access  this  file,  retrieving 
parameters  specified  by  the  user,  and  prepare  tabulations,  statistical  summaries,  histograms, 
and/or  plots  (output  format  will  also  be  selected  by  the  user).  In  addition,  the  model 
output  processor  will  compute  a set  of  summary  parameters  based  on  the  raw  statistics  file 
data  and  save  the  results  in  a performance  summary  file  of  the  data  base. 

All  output  will  be  directed  to  a line-oriented  alphanumeric  device  (e.g.  a high-speed 
printer  or  alphanumeric  terminal)  in  the  default  case.  In  addition,  an  optional 
capability  will  generate  time-series  plots  and/or  class-interval  frequency  distributions 
for  display  on  an  online  vector  graphics  CRT  or  a time-sharing  terminal  printer  with 
vector  plotting  capability. 

The  following  parameters  will  be  sampled  at  specified  intervals  and  output  to  the  raw 
statistics  file.  Maximum,  minimum,  average,  and  variance  for  each  parameter  will  be 
recorded,  except  as  noted.  Both  vehicle  and  passenger  statistics  will  be  recorded  for  total 
time  in  station. 

o Entrance  queue  size 
© Entrance  queue  dwell  time 
9 Number  of  vehicles  at  berths 
o Berth  dwell  time 

o Berth  wait  time  (dwell  time  - time  required  for  deboard/board) 

© Launch  queue  size 
o Launch  queue  dwell  time 
c Vehicle  storage  occupancy 

• Number  of  vehicles  entering  station  (total  only) 
o Number  of  vehicles  bypassing  station  (total  only) 
o Number  of  vehicles  leaving  station  (total  only) 

9 Number  of  entry  rejections  (total  only) 

© Number  of  vehicles  entering  storage  (total  only) 

© Number  of  vehicles  leaving  storage  (total  only) 

© Station  dwell  time  per  vehicle 
o Modal  interchange  entry  queue  size 
a Modal  interchange  entry  queue  dwell  time 

e Number  of  vehicles  entering  from  modal  interchange  (total  only) 

© Number  of  vehicles  leaving  through  modal  interchange  (total  only) 

0 Number  of  arriving  trips  (total  only) 
e Number  of  arriving  transfers  (total  only) 

9 Total  trip  demand  (trips  plus  transfers)  (total  only) 

9 Total  trips  served  (total  only) 

9 Ticketing  queue  size 
9 Ticketing  queue  dwell  time 
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9 Boarding  area  access  queue  size 
9 Boarding  area  access  dwell  time 
9 Outbound  passengers  served  per  vehicle 
9 Inbound  passengers  served  per  vehicle 
9 Through  passengers  served  per  vehicle 

9 Through  modal  interchange  (to  guideway)  passengers  served  per  vehicle 
9 Through  modal  interchange  (to  off -guideway)  passengers  served  per  vehicle 
« Number  of  empty  vehicles  requested  (total  only) 

9 Number  of  empty  vehicles  received  (total  only) 

9 Boarding  area  queue  size 
9 Boarding  area  dwell  time 
9 Total  passenger  dwell  time  in  station 

• Number  of  trips  and  passengers  exiting  the  modeled  area 
» Integral  of  trip-time  and  passenger-time  elapsed  in  modeled  area  for  those 
trips  leaving  the  modeled  area 


As  an  additional  option,  disaggregate  trip  and  vehicle  records  will  be  output  to  a 
separate  file.  This  file  could  then  be  used  as  a basis  for  post-run  analyses  and  recreation 
of  station  events,  without  rerunning  the  DSM. 

Each  vehicle  record  will  consist  of  the  following  data  fields: 

ID 

Time  of  origination 

Source  (on  guideway,  off  guideway,  storage) 

Sink  (on  guideway,  off  guideway,  storage) 

Time  for  each  event 

Trip  records  will  be  generated  for  all  originating  trips,  all  destinating  trips,  and  all 
transfer  trips.  The  trip  records  will  include  the  fields  identified  below: 

Originating  trips 


Origin  time 
Times  for  each  event 
Vehicle  ID  boarded 
Number  of  passengers 

Destinating  trips 


Time  trip  begins  to  deboard 
Time  for  each  deboarding  event 
Vehicle  ID  trip  deboarded  from 
Number  of  passengers 
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Transfer  trips 


Destinating  trip  data 
Originating  trip  data 
Time  trip  joins  boarding  queue 
Number  of  passengers 


2.4  Equipment 

This  section  describes  the  hardware  and  software  requirements  necessary  to  support  the  DSM. 
The  estimates  provided do  not  represent  constraints  on  the  model  development  process  and 
only  provide  broad  guidelines  for  planning  purposes.  The  estimates  given  below  assume  a 
model  configuration  as  previously  defined  with  the  capability  of  supporting  1,000  concurrent 
trips  and  a fleet  size  of  200  vehicles. 


2.4.1  Hardware 

The  following  computing  system  hardware  is  required  as  a minimum  to  support  the  DSM: 

a Central  Processing  Unit  — Must  be  compatible  with  an  IBM  System  370  and 
have  at  least  the  capabilities  of  a Model  145. 


o High  Speed  Core  Storage  — Approximately  195K  bytes  of  problem  program  core 
is  required  which  includes  75K  bytes  for  the  program  logic  and  120K  bytes  for 
data  and  variables.  This  estimate  does  not  include  System  Control  Program 
core  requirements,  which  can  vary  between  300K  bytes  and  2 million  bytes. 


o Direct -Access  Storage  — Storage  requirements  for  various  functional  areas 
of  the  DSM  are  given  below,  in  units  of  IBM  2314  Direct  Access  Storage 
Facility  cylinders  (approximately  144,000  bytes  per  cylinder). 


Program  Development  Libraries 
Input  from  Data  Base 
Structured  Data  File 
Checkpoint  Files 
Raw  Statistical  Output 


20  cylinders 

2 cylinders 

3 cylinders 

10  cylinders  per  checkpoint 
10  cylinders  per  run 


• Magnetic  Tape  — The  DSM  has  no  explicit  requirement  for  magnetic  tape 
storage,  but  it  may  be  a preferable  medium  over  direct -access  storage  for 
the  following  files: 


— Input  from  Data  Base 

— Checkpoint  Files 

— Raw  Statistical  Output 
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2 cylinders 

10  cylinders  per  checkpoint 
10  cylinders  per  run 


The  choice  of  tape  over  disk  will  be  based  primarily  on  the  amount  of  disk 
space  available,  the  frequency  of  access  required,  and  the  operational 
procedures  at  the  computing  center  being  used.  For  planning  purposes,  a 
2,400-foot  reel  of  tape  recorded  at  1600  bytes/inch  has  a capacity  equivalent 
to  320  cylinders  of  2314  disk  space. 


o Unit  Record  Equipment  — The  DSM  will  require  a card  reader  for  input  data 
and  a high-speed  printer  for  output.  Low  volume  input  and  output  can  be 
accomplished  through  a terminal  keyboard/printer. 

• Graphics  CRT  terminal  - The  DSM  will  require  a CRT  with  vector  plotting 
capability  for  output. 

2.4.2  Software 

The  DSM  will  place  certain  requirements  on  the  system  support  software  in  the  areas  of 
system  control  program,  compilers,  linkage  editor,  and  utilities. 

• System  Control  Program  — Use  of  one  of  the  following  will  be  assumed: 

— OS/360  (Operating  System) 

— VS1  (Virtual  Storage  1) 

— VS2  (Virtual  Storage  2) 

— VM370  and  CMS  (Virtual  Machine  and  Conservation  Monitor  System) 

For  terminal -oriented  operation,  the  use  of  the  Time  Sharing  Option  (TSO) 
or  VM/370  will  be  assumed. 

• Compilers  — The  following  compilers  will  be  assumed: 

- FORTRAN  IV  (H  Extended) 

— Assembler  (H) 

— PL/1  Optimizer 

The  majority  of  the  code  will  be  written  in  FORTRAN  IV  (H  Extended), 
with  other  languages  being  used  in  minor  support  functions. 

• Linkage  Editor  — Any  linkage  editor  compatible  with  the  selected  system 
control  program  and  the  compilers  listed  above  will  be  sufficient. 

• Utilities  — The  availability  of  the  standard  Operating  System  360/370  to 
perform  bulk  card-to-disk,  tape-to-tape,  data  set  backup/restore,  and 
data  base  update  will  be  assumed. 
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2.5  Model  Interfaces 


Interfaces  between  the  DSM  and  other  models  are  identified  as  either  data  interrelationships 
or  development  interactions.  Data  interfaces  between  models  are  facilitated  by  the 
centralized  data  base  and  the  input  and  output  processors  associated  with  each  model.  There 
is  no  data  passed  directly  from  one  model  to  another.  Instead,  output  processors  move 
data  into  a centralized  data  base  for  subsequent  manipulation  by  analysts  and  retrieval 
by  input  processors  of  other  models. 

For  example,  the  following  is  a list  of  some  of  the  data  that  would  be  used  by  the  DSM  and 
developed  on  the  basis  of  DESM  runs: 

• Launch  delay  time  distribution 

• Vehicle  arrival  rates 

• Delay  time  distribution  for  getting  an  empty  vehicle 

• Probability  of  a compatible  vehicle  for  demand  responsive  multiparty  service 

• Probability  of  an  empty  vehicle  being  needed  at  a downstream  station  to 
service  a trip 

• Vehicle  demand  file  for  a selected  station 

An  example  of  data  derived  from  the  DSM  which  could  be  used  by  the  DESM  is  the  average 
passenger  access  time  (from  arrival  to  joining  the  trip  queue). 

Development  interactions  exist  where  development  and  analysis  of  the  DSM  help  identify 
event  representations  for  the  DESM  or  system  level  analysis  help  to  quantify  some  of  the 
items  listed  above. 


2.6  User  Interface 


The  general  structure  of  the  DSM  as  shown  in  Figure  4 will  facilitate  user  interface  by 
providing  flexible  input  and  output  procedures.  This  general  structure  is  common  to  all 
of  the  coarse  and  detailed  models. 

Input  and  description  files  will  be  created  and  saved  in  the  data  base  through  system 
utilities  and  terminal  supports.  The  user  then  interacts  with  the  Input  Processor  to  edit 
data  from  the  data  base  and  process  run  time  input  requirements. 

The  Event  Processor  is  driven  by  data  tables  set  up  by  the  Input  Processor  and  generates 
raw  statistics  files  for  use  by  the  Output  Processor.  In  addition,  the  Event  Processor 
generates  checkpoint/ restart  files.  The  structure  of  the  Event  Processor  is  detailed  in  the 
following  Section  3.0,  Modeling  Technique. 

Specific  outputs  to  be  presented  are  determined  by  user  interaction  with  the  Output 
Processor  through  system  utilities  and  terminal  support.  The  output  reports  may  be 
printed  at  an  on  line  terminal  or  on  a high-speed  line  printer  or  may  be  displayed  at 
an  online  graphics  CRT. 
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FIGURE  4 DSM  GENERAL  STRUCTURE 


22 


3.0  MODELING  TECHNIQUE 


The  Event  Processor  will  conform  to  a hierarchical  structure  as  represented  in  the  overview 
in  Figure  5.  This  structure  facilitates  the  flexibility  needed  to  analyze  the  effect  on 
station  performance  of  substitution  of  different  subsystem  configurations  and  algorithm 
versions. 


FIGURE  5 OVERVIEW  OF  EVENT  PROCESSOR 


The  Simulator  Control  is  formed  by  a Main  Module  and  a set  of  Transaction  Management 
Modules.  The  Main  Module  drives  the  Event  Modules,  while  the  Transaction  Management 
Modules  are  used  by  the  Subsystem  Event  Modules  to  perform  bookkeeping  functions  such 
as  event  scheduling  on  a Future  Event  List  and  available  transaction  queueing  in  order  to 
control  the  chronological  flow  of  the  DSM. 

The  Subsystem  Event  Modules  model  the  physical  and  performance  characteristics  of  the 
hardware.  They  request  decisions  from  the  Algorithm  Modules  and,  in  turn,  are  driven 
by  command  data  supplied  by  the  Algorithm  Modules.  They  update  Status  Data  for  the 
components,  trips,  and  vehicles  as  scheduled  events  occur  that  model  physical  changes 
in  the  hardware. 

The  Algorithm  Modules  model  decisions  made  by  the  operational  software  as  requested  by 
the  Subsystem  Event  Modules  and  based  on  current  Status  Data.  They  return  Command 
Data  to  the  Subsystem  Event  Modules. 
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Status  Data  for  Components,  trips,  and  vehicles  are  set  up  by  the  Subsystem  Event  Modules 
for  use  by  the  Algorithm  Modules  to  make  decisions.  Status  Data  is  updated  by  the  Subsystem 
Event  Modules  to  reflect  the  changing  physical  states  of  the  hardware. 

Command  Data  is  set  up  by  the  Algorithm  Modules  to  direct  the  future  actions  of  the 
Subsystem  Event  Modules. 
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4.0  H!PO  DIAGRAMS 


Figure  6 represents  a visual  table  of  contents,  and  Figures  7 through  17  are  HIPO  diagrams 
constituting  the  initial  design  package  for  the  DSM. 
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Detailed 
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FIGURE  6 HIPO  VISUAL  TABLE  OF  CONTENTS 


Trip  Demand  Generation 
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FIGURE  7 TRIP  DEMAND  GENERATION 


1 Vehicle  Demand  Generation-Scheduled  Service 

INPUT  PROCESS  OUTPUT 


I 
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FIGURE  8 VEHICLE  DEMAND  GENERATION-SCHEDULED  SERVICE 


1 .2.2  Vehicle  Demand  Generation  - Demand  Responsive  Service 
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FIGURE  9 VEHICLE  DEMAND  GENERATION  - DEMAND  RESPONSIVE  SERVICE 


2.0  Trip  Management 

INPUT  PROCESS  OUTPUT 
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FIGURE  10  TRIP  MANAGEMENT 


3.1  Vehicle  Selection  - Demand  Responsive  Service 

INPUT  PROCESS  OUTPUT 
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FIGURE  11  VEHICLE  SELECTION-DEMAND  RESPONSIVE  SERVICE 


3.2  Vehicle  Selection  - Scheduled  Service 
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FIGURE  12  VEHICLE  SELECTION-SCHEDULED  SERVICE 
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FIGURE  13  STATION  MANAGEMENT 
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FIGURE  14  EMPTY  VEHICLE  MANAGEMENT 
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FIGURE  15  FAILURE  AND  RECOVERY 


7.1  Results  Reporting  - Data  Collection 
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FIGURE  16  RESULTS  REPORTING-DATA  COLLECTION 


7.2  Results  Reporting  - Report  Generation 
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FIGURE  17  RESULTS  REPORTING-REPORT  GENERATION 


5.0  VERIFICATION 


Program  verification  is  concerned  with  determining  that  the  performance  of  the  simulation 
models  meets  the  requirements  defined  in  the  functional  and  design  specifications.  The 
verification  process  will  start  in  conjunction  with  the  integration  of  the  individual  program 
modules  and  continue  through  the  demonstration  of  the  completed  simulation  system. 

Program  integration  and  testing  will  be  an  extension  of  the  top  down  software  development 
approach.  The  first  software  element  to  be  exercised  and  verified  is  the  highest  level 
system  control  logic.  Then,  successively  lower  levels  of  program  modules  will  be  added 
and  exercised  in  the  environment  of  the  verified  higher  level  routines.  This  procedure 
will  verify  the  vertical  communication  between  the  levels  of  program  modules  in  the 
simulation  system. 

Once  the  complete  simulation  model  has  been  integrated,  verification  will  continue  at  two 
levels:  the  module  level  and  the  system  level.  The  verification  of  input  preprocessor, 
simulation  processor  modules,  and  output  postprocessor  will  be  performed  separately. 

The  input  preprocessor  will  be  verified  manually  by  inspecting  the  data  produced  in  response 
to  prepared  input  data  sets.  The  output  postprocessor's  data  gathering,  statistics 
generation,  and  results  summarization  functions  will  be  verified  manually  or  by  using 
simplified  stand-alone  computer  programs. 

Module  level  testing  of  processor  routines  will  be  supported  by  simulation  facilities  which 
permit  the  tracing  of  an  individual  element  (e.g.,  a vehicle)  through  the  model  and 
printing  key  parameters  each  time  processing  is  performed  on  the  element.  Manual  analysis 
of  the  trace  results  will  establish  the  validity  of  the  lowest  level  program  modules. 

System  level  testing  will  then  be  performed  to  verify  that  the  low  level  functions  interact 
properly.  Test  exercises  will  be  defined,  for  which  the  results  are  relatively  easy  to 
predict.  Such  cases  occur  at  the  extremes  or  boundaries  of  the  range  of  realistic  operational 
conditions.  A final  check  is  made  through  the  definition  of  nominal  test  cases  which  will 
require  significant  effort  to  predict  the  expected  results. 

A test  plan  will  be  developed  which  will  define  the  procedures  for  complete  verification 
of  the  simulation  model.  Separate  tests  will  be  identified  for  the  various  operational  modes 
of  the  model.  The  plan  will  identify  the  methodology,  hierarchy  (sequence  of  testing  and 
test  interdependence),  required  input  conditions,  evaluation  procedures,  and  expected 
resu  I ts . 
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6.0  VALIDATION 


DSM  validation  will  be  controlled  by  a procedure  designed  to  demonstrate  that  the  verified 
model  provides  a valid  representation  of  the  real  world  entity  or  state  of  affairs  it  is 
modeling.  The  validation  process  will  provide  assurance  to  transportation  planners 
that  the  conclusions  reached  and  data  generated  by  these  studies  are  realistic  and  can 
be  used  with  reasonable  conficence.  In  addition,  one  of  the  overall  goals  for  validation  is 
that  test  cases  be  sought  such  that  at  least  one  case  exercises  each  model  feature, 
and  that  the  number  of  such  test  cases  be  the  economical  minimum  that  will  serve  this 
purpose. 

DSM  validation  will  comprise  three  steps: 

1 . Establishing  specific  criteria  for  the  validation  within  the  framework  of  the 

overall  validation  goals.  What  is  to  be  an  acceptable  degree  of  correspondence 
between  the  model  results  and  the  exogenous  information  being  compared 
will  be  specified  in  the  validation  procedure. 

2.  Performing  the  validation  by  one  or  more  of  the  following  methods. 

• Compare  the  model's  prediction  of  performance  to  actual  measured 
performance  for  an  existing  system  under  a set  of  well-defined  test 
conditions 

• Compare  the  model's  prediction  of  performance  of  the  system  to  the 
results  of  a previously  validated  model 

• Compare  the  model  prediction  to  an  estimate  of  system  performance 
derived  by  an  independent  analytical  process. 

3.  And,  reporting  on  how  well  the  validation  exercise  met  the  validation 
goals.  For  example,  should  presently  unavailable  data  be  needed  to  more 
fully  validate  a certain  model  feature,  then  that  needed  data  will  be 
identified.  Also,  the  degree  of  correspondence  between  predicted  and 
actual  information  obtained  will  be  interpreted  for  acceptability. 

To  the  extent  possible,  empirical  data  will  be  the  prime  source  of  DSM  validation  data. 
However,  as  in  the  other  coarse  and  detailed  models,  a multi-stage  process  of  valida- 
tion will  evolve  by  drawing  data  from  each  of  the  three  sources.  For  example,  analytic 
data  derived  from  queueing  theory  will  be  used  to  validate  queues  modeled  in  DSM. 
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APPENDIX 

REPORT  OF  NEW  TECHNOLOGY 


The  Detailed  Station  Model  (DSM)  provides  for  the  first  time  in  one 
program  a wide  range  of  operational  and  performance  measures  of  alternative 
station  configurations  and  management  policies  with  respect  to  vehicle  and 
passenger  handling  capabilities.  This  model  is  integrated  into  the  unique  set 
of  System  Operations  Studies  models  developed  under  this  contract  DOT-TSC-1 220; 
it  accepts  as  input  a stream  of  vehicle  arrivals  at  a specified  station 
computed  by  the  Discrete  Event  Simulation  Model.  Individual  passenger  detailed 
flow  is  eschewed  in  favor  of  passenger  transit  times  at  queues. 
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